The following meanings for the abbreviations used in this specification apply:
3GPP 3rd generation partnership project
ADC Application detection and control
CN Core network
eNB Evolved Node B, E-UTRAN Node B
EPC Evolved packet core
ETSI European telecommunications standards institute
GW Gateway
HSS Home subscriber server
ID Identity, Identifier
IP Internet protocol
ISG Industry specification group
LTE Long term evolution
MEC Mobile edge computing
MME Mobility management entity
PCC Policy and charging control
PCRF Policy and charging rules function
P-GW Packet data network gateway
QoS Quality of service
S-GW Serving gateway
SPR Subscription profile repository
TDF Traffic detection function
UDR User data repository
UE User equipment
Embodiments of the present invention relate to the mobile edge computing (MEC). An MEC server is connected to a radio access network element such as an eNB or a radio network controller (RNC), wherein the MEC server provides applications and services to an UE attached to the eNB. The applications and services offered by a MEC server may be provided by different service providers.
MEC is further described for example in “Mobile-Edge Computing—Introductory Technical White Paper”, September 2014 (Contributors: Huawei, IBM, Intel, Nokia Networks, NTT DOCOMO, Vodafone), and in ETSI ITS(14)01_038: ISG MEC#1 Minutes of Plenary Meeting.
The currently assumed architectural environment is illustrated in the simplified example of FIG. 2. Further details concerning the MEC part can be found in the above-described “Mobile-Edge Computing—Introductory Technical White Paper”, and further details concerning the 3GPP network part can be found e.g. in 3GPP TS 23.401.
Applications and services offered by a MEC server are used by 3GPP mobile network users/subscribers either in sessions between a UE and MEC server or as intermediate data flow manipulators in sessions between a UE and e.g. internet.
A mobile subscriber using MEC services in a session between the UE and MEC server shall somehow be charged for the usage of the radio resources and MEC applications and services, and the charging shall somehow be controlled.
If the current charging and charging control architecture and procedures are applied to applications and services offered by a MEC server, the basic idea of offering low latency applications and services to the users is pretty much lost. As per the current procedures, when an application or service is detected, the detection function in the GW makes an enquiry to the policy controller to fetch policy and charging control rules.
Applying the current policy and charging control and charging architecture to applications and services offered by a MEC server would also be an architecturally heavy solution, with several Diameter based interfaces between a MEC server and core network.
A mobile subscriber using MEC services in a session between the UE and e.g. internet, with a MEC server as intermediate data flow manipulator, shall somehow be charged for the usage of the radio resources, MEC services and core network resources. Current charging mechanisms in the core network charge on what is seen of the service data flows in the core network. This may be different from what is transferred in the radio network, due to the MEC applications/services manipulating the service data flows, and charging by the current core network procedures may not be just or justified. Moreover, the core network charging is not aware of the UE's resource usage on the MEC server.
The users of MEC applications and services are mobile network subscribers. Access control to and charging control on those applications and services may need to be mobile network subscriber specific in certain cases or circumstances.